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DIFFUSION SECURISEE ET PERS ONNAL I SEE DE FLUX AUDIOVISUELS 
PAR UN SYSTEMS HYBRIDE UN I CAST/ MULTICAST 

La presente invention se rapporte au domaine de la 
5 diffusion de sequences audiovisuelles numeriques. 

On.se propose dans la pr6sente invention de fournir un 
procede et un systeme permettant de prot6ger visuellement 
et/ou auditivement une sequence audiovisuelle issue d'un 
standard num6rique, d'une norme num6rique ou d'un standard 

10 proprietaire, de la distribuer de maniSre s6curis6e en mode 
« multicast » & travers un r6seau de telecommunication et de 
reconstituer son contenu original sur un module de 
recomposition de l'6quipement destinataire & partir d'un 
flux audiovisuel num6rique protege. 

15 La pr6sente invention se rapporte plus 

particulierement k un dispositif capable de transmettre de 
fagon s6curis6e & travers un reseau de telecommunication un 
ensemble de flux audiovisuels de haute qualite vers un 6cran 
de . visualisation et/ou vers une sortie audio appartenant & 

20 un terminal ou dispositif d'affichage, tel qu'un 6cran de 
television, un ordinateur ou un terminal mobile de type 
telephone ou PDA (Personal Digital Assistant) , ou autre, 
tout en pr6servant la quality audiovisuelle mais en evitant 
toute utilisation frauduleuse comme la possibilite de faire 

25 des copies pirates des contenus diffuses. L' invention se 
ref£re essentiellement a un proced6 et un systeme client- 
serveur qui protege les contenus audiovisuels en les 
s£parant en deux parties, la deuxidme partie etant 
absolument indispensable pour la reconstitution du flux 

30 original, _ ce dernier etant restitu6 en fonction de la 
recombinaison de la premiere partie avec la deuxieme partie 

Le procede utilise pour la description d'un exemple 
pr6f6re de realisation dans la pr6sente invention s6pare le 
flux audiovisuel en deux parties, de maniere & ce que la 
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premiere partie appel6e « flux principal modifie » contienne 
la quasi-totalit6 de 1' information initiale, par exemple 
plus de 99%, et une deuxi£me partie appel6e « information 
corapl&nentaire » contenant des Elements cibles de 
5 1' information initiale, qui est de tres petite taille par 
rapport a la premiere partie. L' information complementaire 
contient des donn£es extraites du flux original, lesdites 
donn6es extraites 6tant remplac6es par des « leurres » dans 
ledit flux principal modifie, de mani^re a provoquer une 
10 forte degradation audiovisuelle, tout en gardant ledit flux 
principal protege conforme k la norme ou au standard du flux 
original . 

Actuellement, il est possible de transrnettre des flux 
audiovisuels sous forme num6rique via des r6seaux de 

15 diffusion de type hertzien, cable, satellite, etc. ou via 
des reseaux de telecommunication type DSL (Digital 
Subscriber Line) ou BLR (Boucle Locale Radio) ou via des 
r6seaux DAB (Digital Audio Broadcasting) , ainsi que via tout 
r6.seau de telecommunication sans fil de type GSM (Global 

20 System for Mobile), GPRS (General Packet Radio Service), 
UMTS (Universal Mobile Telecommunication System) , Bluetooth, 
Wifi f etc. Par ailleurs, pour 6viter le piratage des ceuvres 
audiovisuelles ainsi dif fusees, ces demi£res sont souvent 
crypt6es ou brouillees par divers moyens bien connus par 

25 l'homme de l'art. 

L'art ant6rieur connait le document U.S. 6295361 
pr£sentant une methode et un dispositif permettant a un noeud 
de gestion de cl6s a decider du processus de changement de 
30 la cle de groupe de certains noeuds au sein d'un groupe 
multicast, & l'aide d'un indicateur ins6r6 dans un paquet 
multicast. Le noeud gestionnaire decide comment insurer 
1' indicateur et quels sont les noeuds concern6s . La nouvelle 
cle est alors envoy£e et lorsque tous les noeuds du groupe 
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ont regu leur cl6, le noeud gestionnaire envoie un 
indicateur, ou bien une date a partir desquels tous les 
membres du groupe sont autorises a utiliser les nouvelles 
cl6s. Cet art anterieur repr6sente une methode de gestion de 
5 la session multicast a 1'aide de changement dynamique de 
cles de groupe , la m§me cl6 etant attribute a tous les 
membres du meme groupe, & l'aide de laquelle les donnees 
seront d6crypt6es. Toutefois, la protection utilisee est le 
cryptage et toutes les donnees initialement pr^sentes dans 

10 le flux audiovisuel res tent a l'int6rieur du flux prot§g§. 
Par consequent , cet art anterieur ne r6sout pas le probleme 
de haute s6curisation et personnalisation, objet de la 
pr6sente invention. 

I/art anterieur fait 6galement reference au document 

15 WO 02/11356 A2 qui pr6sente une methode pour la gestion de 
cles entre le client et le serveur dans un environnement 
multicast. La methode est basee sur 1' 6tablissement d'un 
canal s6curis6 entre le serveur et le client en utilisant un 
protocole SSL (Secure Socket Layer) ou TLS (Transport Layer 

20 Security) avec certaines modifications de l'ordre d'echange 
de messages , afin de pouvoir g6n6rer une cle de gestion et 
d' envoyer cette cl6 au client cL travers ledit canal 
s6curis6, a partir de cette cl6, le client genere la future 
cl6 de session avec le serveur. Les clients d'un m§me groupe 

25 multicast utilisent la meme cl6 de gestion pour g6n6rer une 
cl6 de session pendant la session de communication. Cet art 
anterieur ne correspond pas aux criteres de transport 
s§curis6 de donnees audiovisuelles, objet de la pr6sente 
invention, les donnees, meme crypt6es, etant int6gralement 

30 prdsentes dans le flux de donn6es proteg£. 

A la difference de l'art anterieur , la pr6sente 
invention propose un systeme se caract6risant par la 
diffusion en multicast de 1' information compl&nentaire, un 
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traitement est effectu6 en temps r6el sur des segments 
repr6sentant des entites ind6pendantes de point de vue 
traitement, lesdits segments comportant des donnees pour la 
reconstruction, de 1' information audiovisuelle complete, 
5 lesdits segments etant s6curis6s et personnalis6s pour 
chaque utilisateur, et envoy6s aux equipements destinataires 
en temps r6el via un r6seau de faible bande passante r a 
partir d'un serveur central jouant le rdle de controleur 
d'acces pour la visualisation des contenus. 

10 Dans la pr6sente invention, on entend par le terme 

« multicast » un mode de transmission k partir d'un 6metteur 
vers tous les r^cepteurs qui appartiennent au meme groupe 
d'abonn6s, a la difference du terme « unicast » qui 
represente un mode de transmission & partir d'un femetteur 

15 vers un seul r6cepteur. 

La protection appliquee aux contenus distribu6s par le 
systeme multicast s6curis6, objet de la pr6sente invention, 
est bas6e sur le principe de suppression et de remplacement 
de certaines informations presentes dans le signal 

20 audiovisuel originel encode, par une m6thode quelconque, 
soit : substitution, modification, permutation ou 
deplacement de 1' information. La solution consiste k 
extraire et a conserver en permanence dans un serveur 
s6curis6 ladite information compl&nentaire, contenant une 

25 partie du flux audiovisuel originel , cette partie 6tant 
indispensable pour reconstituer ledit programme audiovisuel, 
mais etant d'un volume tres faible par rapport au volume 
total du programme audiovisuel enregistrfe chez l'usager ou 
resu en temps r6el par cet usager. Ladite information 

30 compl6mentaire est transmise en mode multicast via le r6seau 
s6curis6 de transmission au moment de la visualisation et/ou 
de 1' audition dudit programme audiovisuel. 

Le fait d' avoir enlev6 et substitue par des leurres 
une partie des donn6es originales du flux audiovisuel 
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initial lors de la generation du flux principal modifie, ne 
permet pas la restitution dudit flux d'origine & partir 
dudit flux principal modifi6, qui est enti£rement compatible 
avec le format du flux d'origine, et peut done §tre copi6 et 
5 lu par un lecteur classique. Ledit flux principal modifie 
est toutefois compl&tement incoherent de point de vue 
perception audiovisuelle humaine. 

Le flux numerique originel 6tant separ6 en deux 
parties, la plus grande par tie du flux audiovisuel, ledit 
flux principal modifife, sera done transmise via un r6seau de 
diffusion classique, alors que la partie manquante, ladite 
information compl6mentaire, sera envoyee a la demande via un 
reseau de telecommunication bande 6troite, ou encore via un 
support physique comme une carte a m6moire, un disque, etc. 
Toutefois, les deux r6seaux peuvent §tre confondus, tout en 
gardant les deux voies de transmission s6parees. Pour la 
reconstitution du flux original, 1' information , * 
compl6mentaire est envoy6e piece par pi£ce pendant la 
visualisation et/ou 1' audition du flux audiovisuel. 

L'objet de la pr6sente invention est la transmission 
s6curis6e et personnalis6e, apres authentif ication de 

10 1'utilisateur, de 1' information compl6mentaire en mode 
multicast, de manidre a 6viter k ce qu'elle puisse etre 
copi6e ou tomber int6gralement en possession de 
1' utilisateur ou de toute personne mal intentionnee. 

La distribution en multicast est utilis6e dans les cas 

15 oil un grand nombre d' utilisateurs veut acc6der au m§me 
contenu et en meme temps, ce qui est par exemple le cas de 
la diffusion en direct via satellite ou sur le c§ble ou sur 
tout autre r6seau permettant d'atteindre plusieurs abonn6s 
en mSme temps. Le flux de contenu est transmis & partir d'un 

20 serveur vers les clients via un canal multicast. Par une 
voie s6par6e, 1' information compl6mentaire d6sign6e et 
personnalis6e pour chaque client actif (membre du groupe 
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multicast) est dif fusee a partir d'un serveur s6curise 
egalement en multicast. L'utilisateur qui est int6resse par 
un contenu, re joint le groupe multicast , re<poit 
1' information complementaire en fonction de ses droits 
5 permettant ainsi la reconstitution du flux original et done 
la visualisation simultanfement a la reception de ladite 
information complementaire . 

D'un cot6, le benefice de la distribution en mode 
multicast de 1' information complementaire est qu f un serveur 

10 centralist peut modeler sa distribution vers un tres grand 
nombre de consomraateurs • D f un autre cote, 1' inconvenient de 
la distribution en multicast est que la m§me information 
complementaire est transmise vers tous les utilisateurs du 
groupe et par consequent, il est plus difficile de controler 

15 individuellement les diff£rents consommateurs . 

De point de vue s6curit6 et protection de contenus, le 
multicast pr6sente les d6savantages des modules "un-vers- 
plusieurs" ou « un seul 6metteur, plusieurs recepteurs » de 
1' expression en anglais « one-to-many » qui d6signe une 

20 operation de communication 6manant d'un seul emetteur et 
s'adressant & de multiples recepteurs- D' oH la necessity 
d'eiaborer un systerae de protection pour la distribution 
multicast fiable et se basant sur les caracteristiques 
suivantes : 

25 • La solution de la pr6sente invention est 

complementaire au protocole de distribution en multicast 
« rejoindre/quitter le groupe » bien connu par l'homme de 
l'art ; 

• La prise de decision pour rejoindre/quitter le 
30 groupe est effectu6e au niveau des elements, d'acces du 
r6seau pour le contr61e d'acces a partir d'une liste 
prealablement 6tablie, oil le client regoit la permission de 
rejoindre ce groupe, mais sans avoir le droit & cette etape, 
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de visualiser le flux diffuse pour ce groupe, lesdits 
616ments d'accds 6tant appel6s des commutateurs ; 

• Les utilisateurs auxquels un commutateur a refuse 
l'autorisation ne peuvent pas rejoindre le groupe ; 

5 • Le serveur central est responsable de la mise & 

jour de la liste des clients et de la prise de decision pour 
inclure de nouvelles identit6s sur la liste des cles de 
cryptage pour la session, apr^s une premiere 6tape 
d' authentif ication avec le client voulant rejoindre le 
10 groupe; 

• Chaque cl6 de session est individuelle a chaque 
client et possede sa propre duree de vie, apr£s laquelle 
elle est consideree comme une cl6 non valide, elle est alors 
d6truite par le serveur ; 

15 • L'6chelle d'un groupe multicast est de l'ordre de 

plusieurs milliers d' utilisateurs par groupe; 

• La relation est du type un-vers-tous dans une 
seule direction , par consequent le serveur est tou jours la 
source d' emission et les clients tou jours les r6cepteurs, a 

20 1' exception des requetes 6mises depuis les r6cepteurs vers 
le serveur par un lien de retour en unicast, ou par exemple 
pendant l'6tape de 1' authentif ication. 

La particularity de la presente invention est que le 
25 serveur diffuse en multicast vers un grand nombre 
d' utilisateurs pouvant rejoindre et quitter le groupe de 
mani^re dynamique. De plus, dans la presente invention , 1 
supprime la fonctionnalit£ de relation selective ("push 
relation" en anglais), c' est-i-dire que les clients d'un 
30 m§me groupe ne peuvent pas communiquer entre eux et par 
consequent le module de connexion multicast est simplifi6, 
tout comme le protocole de gestion et de distribution de 
cles pour les membres du groupe. 
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I/objet de la presente invention est un protocole 
simplifie pour la diffusion securisee de 1' information 
complementaire en multicast, compl6tant ainsi^les protocoles 
multicast de diffusion existants avec un protocole de 
5 diffusion s6curis6e de ladite information complementaire. 

A cet effet, 1' invention concerne selon son acception 
la plus generale un proc6de pour la distribution securisde 
de flux audiovisuels numferiques selon un format standard, 
normalise ou proprietaire, lesdits flux sur lesquels on 
10 procdde, avant la transmission a l'6quipement destinataire, 
& une separation du flux en deux parties pour gen^rer un 
flux principal modifie, pr6sentant le format du flux 
original, et une information complementaire d'un format 
quelconque, comportant les informations num6riques aptes £ 
15 permettre la reconstruction du flux original, caract^rise en 
ce que l'on transmet par voies s6parees pendant la phase de 
distribution ledit flux principal modifie k partir d'un 
serveur de distribution, £ ce que l'on transmet en mode 
multicast l&dite information complement aire vers ledit 
20 6quipement destinataire depuis un serveur central s6curis6 
en passant par au moins un routeur et au moins un 
commutateur reliant ledit 6quipement destinataire audit 
serveur central via au moins un point d' acces - 

De preference, 1' authentification entre le client et 
25 le serveur s'effectue en mode unicast. 

Selon un mode de mise en ceuvre particulier, une cie de 
session unique par contenu et par client est generee par le 
serveur central suite k ladite authentification. 

Avantageusement, 1' information complementaire est 
30 compressee et cryptee avant 1' envoi au client. 

Selon une variante, la gestion d'un groupe de 
multicast s'effectue dans la couche de liaison contrClant la 
distribution des donn6es en multicast, uniquement pour le 
point d' acc^s concerne. 
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De preference, la gestion et la securisation de 
1' information compiementaire, est effectuee suite a une 
multi-reception de demandes d' authentif ication par un 
serveur central , et comprend une etape de compression, une 
5 6tape de cryptage et une etape de gestion desdites cles de 
session. 

Selon un mode de realisation pr6f 6rentiel, la 
regeneration d'une nouvelle cl6 de session pour le client 
est effectuee en fonction de la decision du client de 

10 prolonger la connexion, est bas6e sur la dur6e de vie de la 
precedente cle de session, et est individuelle pour chaque 
membre du groupe multicast. 

Selon un autre mode de realisation, 1' information 
compiementaire est securisee et personnalis6e pour chaque 

15 client et pour chaque session multicast k l'aide de methodes 
de cryptage hybrides ou symetriques ou asymetriques . 

L 1 invention concerne 6galeraent un syst&ne pour la 
distribution s6curis6e de flux audiovisuels caracteris6 en 
ce que le contr81e de debit dans le groupe multicast est 

20 effectue suite k la gestion et & la personnalisation de la 
securisation de 1' information compiementaire. 

De preference, le systeme selon 1 T invention comporte 
un dispositif de separation du flux video original en un 
flux principal modi fie et en une information compiementaire, 

25 au moins un serveur multimedia contenant les flux 
audiovisuels proteges, au moins un serveur central securise 
comprenant un dispositif de securisation et de 
personnalisation de ladite information compl6mentaire, & 
partir duquel est distribu6e 1' information compl6mentaire, 

30 au moins un r6seau de telecommunication, au moins un 
routeur, au moins un commutateur servant de point d'acc^s 
pour la connexion avec l'equipement destinataire et un 
dispositif sur l'equipement destinataire pour la 
reconstruction du flux audiovisuel original en fonction 
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dudit flux principal modifie et de ladite information 
complementaire . 

La pr6sente invention sera mieux comprise & l'aide des 
exemples de realisation et des etapes d6tailiees suivants. 
5 Un exemple de realisation pr6f6r6, mais non limitatif , 

du proced6 qui r6pond aux criteres de s6curite et de 
fiabilite est illustre grfice au syst&ae client - serveur 
presente sur la figure. 

Le flux audiovisuel sous forme numerique (1), transmis 

10 via le lien (6) au module d' analyse et d' embrouillage (2), 
est s6par6 en deux parties par ce module (2) . Le flux 
principal modifi6 (17) est stocke dans un serveur multimedia 
(16) et est envoy6 en temps r£el au client pendant la 
visualisation via un reseau large bande ou bien est stocke 

15 au pr Salable sur le dispositif de sauvegarde du terminal 
(14) de 1' utilisateur. L' information complementaire (3) est 
envoyee dans le module de stockage et de segmentation (41) 
du serveur central securise (4) . 

L' information complementaire 6tant envoy6e uniquement 

20 & la demande, sa distribution en temps r6el, sa securisation 
et sa personnalisation pour chaque utilisateur est realisee 
grace & la propri6te de « scalabilite en d6bit » sur les 
reseaux de transport. On definit la notion de « scalabilite 
en debit » corame la capacite d'un r6seau de g6rer, de 

25 modifier, de r6partir et d' adapter le debit des flux qui 
transitent en fonction de la bande passante disponible ou 
negoci6e et en fonction des congestions du reseau. Grace au 
faible debit de 1' information complementaire transmise en 
temps r6el, le proced6 de la pr6sente invention contient une 

30 etape de segmentation de 1' information complementaire dans 
le module (41), qui g6n£re des segments de donn6es de taille 
variable, chaque segment correspondant a un element 
audiovisuel entier subjectivement coherent, tel qu'une image 
ou une trame, un groupe d' images ou GOP (« Group Of 
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Pictures » en anglais) dans un flux MPEG-2 par exemple. Dans 
une variante, la segmentation est effectu^e en une seule 
etape apr£s la generation de ladite information 
complementaire (3) et produit une serie de segments d6signes 
5 comme « flux d' information complementaire » qui restent 
stockes dans le module de stockage et segmentation (41) . 
Dans une autre variante, le flux d' information 
complementaire est g6n6r6 en temps r6el. 

L'6tape de segmentation de 1' information 

10 complementaire est suivie par une etape d' encapsulation en 
blocs de donnees et une etape de cryptage dans le module 
(42) , precedes par une etape de compression de leur taille, 
oii les blocs restent disponibles k la deraande de la part des 
utilisateurs , Le flux d' information complementaire est 

15 envoy6 vers le terminal (14) de l'utilisateur en continu 
sous forme de blocs, un bloc contenant un segment auquel ont. 
et6 rajoutees des informations d'acces ou «ent§te» 
comportant des donnees relatives k 1' identity de 
l'utilisateur, dans le cas d'un r6seau classique centralise. 

20 De pr6f6rence, l'ent§te comporte des donnees relatives k la 
mobilite de l'utilisateur (position, droits, points d'acces 
r6seau par exemple) dans le cas d'un reseau reparti. 
Avantageusement, l'entete comporte des donnees relatives aux 
cl6s de cryptage du flux d' information complementaire. Un 

25 bloc est 1' unite fondamentale de communication, il est 
appeie aussi UFIC (Unite de Flux d' Information 
Complementaire) . 

Lorsque l'utilisateur « i » souhaite visionner une 
sequence., il se connecte via son 6quipement (14i) et le lien 

30 (13i) a son point d'acces le plus proche, le commutateur 
(12a), qui lui a donne au prealable 1' autorisation de 
rejoindre le groupe multicast. Le commutateur (12a) redirige 
la requete via le lien (11a) vers un routeur local (10a) , ce 
dernier adresse k son tour la demande via le lien (9a) vers 
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un routeur central (8) , ledit routeur central (8) s'adresse 
au serveur central (4) via le lien (7) . Lorsque le serveur 
(4) regoit ainsi la requete du client (14i) , le serveur 
central (4) exige une authentification de la part de ce 
5 client (14i) afin de decider 1' envoi des UFICs sollicit^es, 
qui sont uniques par titre de sequence audiovisuelle . Apr£s 
le dialogue d' authentification, 1' identification du client 
(14i) par le serveur central (4) comme figurant dans sa base 
de donn6es (5) et la generation d'une cie de session unique, 

10 le flux segment^ dans le module (41) est envoye via le lien 
(43) au module (42), compress^ et crypte dans ce module (42) 
par ladite cie de session unique par titre et par client. 
Les UFICs sont ensuite transpprt6es via la liaison (7) , le 
routeur central (8) f le lien (9a) , le routeur local (10a) , 

15 le lien (11a) , le commutateur (12a) et le lien (13i) vers le 
terminal (14i) de 1' utilisateur (i) . Avantageusement, le 
terminal (14i) de 1' utilisateur est 6quip6 d'une carte 4 
puce (15i) , sur laquelle s'effectue le decryptage des unites 
du flux d' information complementaire . 

20 Le commutateur (12a) est le responsable de la 

s6curite, il controle les adresses des clients dans la liste 
d'acces composee d' informations relatives aux sessions 
pr6c6dentes avec le client (par exemple, temps et dur6e de 
connexion, paiement anticipe ou retard^, type de contenus 

25 visualises) , cela assure la personnalisation de chaque 
session client done de 1' information complementaire en 
f ormant des unites UFICs . Un mode de mise en ceuvre est 
1' utilisation d'une methode hybride, comme par exemple 
utiliser l'unicast pour 1' authentification k l'aide de cl6s 

30 s6curis6es et le multicast pour la diffusion de 
1 ' information complementaire . 

En premier lieu, si le client (14i) reussi a rejoindre 
le groupe multicast souhaite via le commutateur (12a), e'est 
qu'il poss^de une identity reconnue et une autorisation de 
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la part du r6seau pour recevoir lesdits paquets 
d' information complementaire apres 1' etape 

d'authentification; toutefois, tant qu'une cle de session 
valide n'a pas 6te g^neree par le serveur central, le client 
5 ne peut pas utiliser les UFICs, lesdites UFICs 6tant 
diffus6es et crypt6es uniquement avec les cl6s des autres 
utilisateurs (14j, 14k, etc.). 

En second lieu, le client dialogue avec le serveur 
d' information complementaire (4) dans une liaison point-cL- 

10 point en unicast, la phase d'authentification est ainsi 
effectu6e pour s' assurer que le client poss£de suffisamment 
de droits pour recevoir des UFICs et pour generer la cle de 
session (k travers une m6thode d'echange d' informations 
s6curis6e) , les droits de visualisation 6tant sauvegard6s 

15 dans une base de donn6es de gestion des droits (5) . 

A la fin de cette etape, le serveur (4) raj out e 
automat iquement la nouvelle cl6 du client (14i) dans la 
liste de cl6s de session correspondant au groupe multicast 
sollicite. 

20 Le serveur (4) commence cL crypter l'UFIC courant avec 

la cl6 de session et envoie l'UFIC avec ce qui est appel6e 
une etiquette qui est d61ivr6e au client pendant 1' etape 
d'authentification. Ladite Etiquette contient 1' information 
sur une association unique entre l'UFIC crypt^e et chaque 

25 Client. Le client (14i) regoit des groupes de paquets, tant 
qu'il detient ladite 6tiquette valide et d^crypte les 
portions de donn6es avec ladite cl§ de session, jusqu'a ce 
que la duree de vie de ladite cle de session expire, 

Apr6s une p6riode suffisamment longue pour avoir le 

30 droit demander une nouvelle cl6 et dans le cas oil le client 
qui souhaiterait continuer k recevoir 1' information 
complementaire du meme groupe multicast, recommence une 
nouvelle 6tape d'authentification. 
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Avantageusement, le serveur (4) crypte les UFICs 
correspondantes k une diffusion simultanee du meme contenu 
avec les cles de session de tous les clients autorises 14i, 
14 j, 14k,...., 14q et envoie un certain nombre de fois la m§me 
UFIC crypt6e avec chaque cl6 differente, correspondant au 
nombre de clients connect6s. 

De pr6f6rence, avant le cryptage avec toutes les cl6s 
de session, est appliquee une compression des unites de flux 
d' information compl6mentaire, r§duisant le volume 
d' information & transporter et augmentant aussi la 
s^curisation des UFICs crypt6es par la suite, en r6duisant 
la redondance, car beaucoup d' analyses cryptographiques 
exploitent la redondance afin de casser la protection. 
I/efficacit6 de 1'algorithme de compression est aussi un des 
facteurs qui gdre la scalabilite en d§bit du groupe 
multicast en fonction du nombre des membres par groupe. 

Chaque utilisateur d6crypte les UFICs regues £ l'aide 
de sa propre cl6 de session. 

On entend par "cycle de transmission du serveur" 
l'etape d' envoi d'une UFIC sous forme compress6e, cryptee 
avec toutes les cles des membres du groupe vers l'adresse et 
le num6ro de port du groupe multicast. 

Un avantage de cette technique est qu'elle assure une 
resistance au piratage due au fait qu r on applique un 
cryptage multiple du m§me contenu avec diff6rentes cles pour 
les diff6rents equipements destinataires . Le m6canisme de 
compression est applique pour le cycle de transmission du 
serveur afin d'6viter un trafic trop 61ev6 pour les groupes 
ayant un nombre important de membres (plusieurs milliers 
d' utilisateurs) . Ce raodele est apte a utiliser n'importe 
quel algorithme de compression sans perte de type LZ 
(Lempel-Ziv) , par exemple LZW (une variante de LZ par Terry 
Welch's), LZJH (Lempel-Ziv-Jeff-Heath ou v. 44 par ITU-T). 
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Des renouvel lenient s p6riodiques des cl6s de session 
sont effectues, afin d r as surer leur s6curit6 
cryptographique . Par exemple une cle de session peut §tre 
valable pour une dur6e de deux heures, durant laquelle la 
cl6 va dechiffrer une quantite d'UFICs ayant un d6bit d'une 
dizaine de Kbits/s, 6gale par exemple a 2 20 blocks de donnees 
chacun long de 64 bits. 

Une extension sur la fonction d' observation des 
messages du groupe multicast (« snooping » en anglais) du 
protocole IGMP (Internet Group Management Protocol) sur le 
dernier point de distribution (12) est utilis6e dans la 
couche liaison pour la gestion d'acces (autoriser ou 
interdire) pour chaque client sur les flux auxquels ledit 
client possdde ou non les droits et en consequence optimise 
la bande passante pour chaque client en son point d' acces, 
comme par exemple un DSLAM (Digital Subscriber Line Access 
Multiplixer) d'un reseau DSL (Digital Subscriber Line) . 
Ladite extension sur la fonction d' observation apporte ainsi 
un mode de transmission multicast 6tendu et securise. 
Pendant la phase de distribution ladite information 
compl6mentaire est ainsi transmise en mode de transmission 
multicast etendu et securis6 vers ledit 6quipement 
destinataire depuis un serveur central s6curis6 en passant 
par au raoins un routeur et au moins un commutateur reliant 
ledit 6quipement destinataire audit serveur central via au 
moins un point d'acces. Le systdme garde la personnalisation 
des UFICs pour chaque client, tout en r6duisant le nombre de 
connections unicast par serveur, £ 1' exception des moments 
d f authentification. Le syst^me optimise 6galement le debit 
done la quantite de donn6es a transmettre en fonction de la 
variation du nombre de clients par groupe. Ainsi, la 
gestion d'acces et la personnalisation de 1' information 
compl6mentaire (UFIC) contr61ent le d6bit dans le groupe 
multicast. La version actuelle du protocole IGMP permet aux 
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commutateurs (12) de detecter les messages IGMP des clients 
membres, d'envoyer la reponse respective et de contr61er la 
distribution des paquets en multicast jusqu'au port du 
client. Dans la pr6sente invention, cette fonction est 
5 completee par un filtrage relatif au premier niveau de 
controle avec une liste d'adresses de la couche liaison MAC 
(Medium Access Control) , lesdites adresses repr^sentant les 
clients autorises a se connecter au groupe multicast. 

De plus, un marquage avec une Etiquette est rajout<§ 
10 pour chaque paquet de donn6es compress^ et crypte, qui 
represente 1' identity du client et aussi un second niveau de 
contr81e et de personnalisation. 

Cette identity est utilis6e par le commutateur (12) 
pour determiner le port physique vers lequel les paquets 
15 sont distribu^s, en envoyant au client donn6, uniquement les 
paquets marques avec sa propre Etiquette. 

Selon une variante, les UFICs sont crypt6es a l'aide 
d' algorithmes de cryptage sym^triques et la cl6 de cryptage 
est ensuite crypt6e avec une cl6 publique du destinataire. 
20 C'est un mode d' authentif ication hybride. 

Selon une autre variante, les UFICS sont crypt6es a 
l'aide d f algorithmes de cryptage asym6triques et c f est un 
mode d' authentif ication PKI (« Public Key Infrastructure » 
en anglais) . 

25 La pr6sente invention sera illustr6e 4 l'aide d'un 

deuxieme exemple de realisation pr6f6r6, qui inclut un 
protocole multicast, une m6thode d' authentif ication mutuelle 
et une methode de compression pour le serveur comprenant des 
protocoles de multicast utilises et leur extension pour la 

30 distribution de 1' information complementaire, objet de la 
pr6sente invention. 

Le systSme de transmission multicast est bas6 sur un 
protocole de gestion de groupe (IGMP) qui est responsable du 
contr61e pour rejoindre/quitter le groupe multicast. Ce 
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protocole est execute entre le client (14i, 14 j , 14k) et son 
point d'acces reseau respectivement le plus proche, le 
commutateur (12a) . Un protocole de routage multicast 
contr61e le routage du trafic multicast depuis les 
5 commutateurs (12) vers tous les routeurs (10) du r6seau de 
distribution. 

Un processeur de controle situ6 i l'int^rieur du 
commutateur (12) observe les messages IGMP envoy^s par les 
clients (14) . Les commutateurs capables de gerer et d' 6muler 

10 des messages IGMP utilisent 6galement cette information pour 
configurer dynamiquement leurs propres filtres 
d' observation - 

Cette solution optimise la gestion de la bande 
passante au niveau des commutateurs, en 6vitant la surcharge 

15 des LAN (« Local Area Network » en anglais), surtout dans 
des cas oti 1' utilisateur final commute fr^quemment d'un 
groupe de multicast & un autre, par exemple lors d'un 
changement de chaine de t616vision 

Les routeurs (10) en support de routage multicast et 

20 les commutateurs (12), pour lesquels la couche 3 du module 
OSI est capable de g6rer les donn6es, utilises pour cet 
exemple, contiennent un controle de bande passante avec une 
fonctionnalite de limitation du d6bit en IP multicast qui 
permet d'imposer une limite sup^rieure pour le trafic 

25 effectue depuis le serveur vers les groupes multicast- Le 
m6canisme de definition des limites inclut la definition 
d'un filtre de source multicast et d'un filtre recepteur de 
groupe multicast par port de reception. Ce filtre de 
contrSle est bas6 sur l'adresse IP ou 6galement sur 

30 l'adresse MAC (Adresse de la carte rdseau « Medium Access 
Control ») , en utilisant par exemple le m6canisme MVR 
(Multicast VLAN Registration) et par consequent pour 6viter 
une attribution frauduleuse (« spoofing » en anglais) de 
l'adresse r&seau IP du client, un protocole complementaire 
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est applique en unicast « Unicast Reverse Path Forwarding » 
(URPF) entre le client (14) et le commutateur (12) . 



WO 2005/053299 



19 



PCT/FR2004/050613 



RE VEND I CAT I ONS 

1. Procede pour la distribution securisee de flux 
audiovisuels numeriques selon un format standard, normalise 
ou propri6taire, lesdits flux sur lesquels on procede, avant 
la transmission & l'equipement destinataire, a une 
separation du flux en deux parties pour g6n6rer un flux 
principal modifie, presentant le format du flux original, et 
une information complementaire d'un format quelconque, 
comportant les informations numeriques aptes a permettre la 
reconstruction du flux original, caract6ris6 en ce que l'on 
transmet par voies separ6es pendant la phase de distribution 
ledit flux principal modifi6 a partir d'un serveur de 
distribution, k ce que l'on transmet en mode multicast 
etendue s6curis6 ladite information complementaire vers 
ledit 6quipement destinataire depuis un serveur central 
s6curis6 en passant par au moins un routeur et au moins un 
commutateur reliant ledit 6quipement destinataire audit 
serveur central via au moins un point d r acces . 

2. Proc6d6 pour la distribution s6curis6e de flux 
audiovisuels selon la revendication 1, caract6ris6 en ce que 
1' authentification entre le client et le serveur s'effectue 
en mode unicast. 

3. Procede pour la distribution s6curis6e de flux 
audiovisuels selon la revendication 2, caract6ris6 en ce que 
suite & ladite authentification, une cl6 de session unique 
par contenu et par client est g6n6ree par le serveur 
central . 

4. Proc6d6 pour la distribution s6curis6e de flux 
audiovisuels selon la revendication 3, caract6ris6 en ce que 
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1' information complement aire est compressee et cryptee avant 
1' envoi au client • 

5. Proc6d6 pour la distribution s6curis6e de flux 
5 audiovisuels selon l'une des revendications pr6c6dentes, 

caracterisfe en ce que la gestion d'un groupe de multicast 
s'effectue dans la couche de liaison s^curisant l'acc^s & la 
distribution des donn6es en multicast, uniquement pour le 
point d'acc^s concern^. 

10 

6. Procede pour la distribution securisee de flux 
audiovisuels selon l'une des revendications pr6c6dentes, 
caract6ris6 en ce que la gestion et la s6curisation de 
1' information complementaire, est effectuee suite k une 

15 multi-reception de demandes d'authentification par un 
serveur central , et comprend une 6tape de compression, une 
6tape de cryptage et une etape de gestion desdites cl6s de 
session. 

20 7. Proc6d6 pour la distribution s6curisee de flux 

audiovisuels selon l'une des revendications pr6c6dentes, 
caracteris6 en ce que la r6g6n6ration d'une nouvelle cle de 
session pour le client est effectu6e en fonction de la 
decision du client de prolonger la connexion, est bas6e sur 

25 la duree de vie de la pr6c6dente cl6 de session, et est 
individuelle pour chaque merabre du groupe multicast. 

8. Proc6d6 pour la distribution s6curis6e de flux 
audiovisuels selon l'une des revendications pr6c6dentes, 
30 caract^rise en ce que 1' information compl6mentaire est 
s6curis6e et personnalisee pour chaque client et pour chaque 
session multicast a l'aide de m6thodes de cryptage hybrides 
ou sym6triques ou asym6triques . 
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9. Syst&me pour la distribution s6curisee de flux 
audiovisuels selon l'une des revendications precedentes, 
caracteris6 en ce que le controle de debit dans le groupe 
multicast est effectue en consequence de la s6curisation et 
5 de la personnalisation de 1' information compiementaire. 

10. Systeme pour la distribution securis^e de flux 
audiovisuels pour la mise en oeuvre du proc6d6 selon l'une 
des revendications precedentes, caract6ris6 en ce qu'il 

10 comporte un dispositif de separation du flux vid6o original 
en un flux principal modifie et en une information 
compiementaire, au moins un serveur multimedia contenant les 
flux audiovisuels proteges, au moins un serveur central 
s6curise comprenant un dispositif de securisation et de 

15 personnalisation de ladite information complement aire , a 
partir duquel est distribute 1' information compiementaire, 
au moins un reseau de telecommunication, au moins un 
routeur, au moins un commutateur servant de point d'acc£s 
pour la connexion avec 1 ' equipement destinataire et un 

20 dispositif sur 1' equipement destinataire pour la 
reconstruction du flux audiovisuel original en fonction 
dudit flux principal modifie et de ladite information 
compiementaire . 
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